Fix(registry): sudoku-04 -- index d'attestation 0023 duplique sur main + sha C# perime by jsboige · Pull Request #24618 · jsboige/CoursIA

jsboige · 2026-11-04T08:57:30Z

Grain: MED/ledger -- lane myia-ai-01:CoursIA-2 -- prev: MED/guard #24609

Ce que fait cette PR

Répare le rouge de base Scripts Tests (CPU) que ma PR #24609 a hérité de main, sur le registre des attestations jumelles de la paire Sudoku-04 SimulatedAnnealing.

Deux défauts distincts, une seule cause racine côté registre :

index d'attestation dupliqué — deux fichiers d'audit au même index 0023 dans scripts/notebook_tools/twin_pairs.d/sudoku-04-simulatedannealing/ ;
sha C# périmé dans mes deux attestations du 2026-11-01, qui enregistrent un état du jumeau C# déjà dépassé à cette date.

Preuve du rouge (base-inherited, mesuré)

Sur origin/main, le registre porte deux fichiers au même index :

0023-2026-10-31-myia-po-2025-CoursIA.yaml
0023-2026-11-01-myia-ai-01-CoursIA-2.yaml

L'index zero-padé est la clé de tri du journal file-per-audit (sorted(glob) restitue l'ordre d'append, #14911) : deux entrées au même index rendent leur ordre relatif dépendant du reste du nom.

Les deux gardes qui rougissent sur main — mesurés dans ce worktree avant la réparation :

FAILED scripts/notebook_tools/tests/test_twin_registry_integrity.py::
  test_audit_index_unique_and_no_identical_duplicates_per_pair
  E  prefixe NNNN duplique dans une paire : ['sudoku-04-simulatedannealing:
     0023-2026-10-31-myia-po-2025-CoursIA.yaml et 0023-2026-11-01-myia-ai-01-CoursIA-2.yaml']

FAILED scripts/notebook_tools/tests/test_twin_index_collisions.py::
  test_le_registre_de_la_revision_testee_ne_porte_aucun_doublon_intra_revision
  E  doublon d'index intra-revision sur la revision testee : [{'pair':
     'sudoku-04-simulatedannealing', 'index': '0023', 'refs': ['HEAD'], 'names': [...]}]

Les deux fichiers sont déjà sur main (le mien a été mergé par #23870) : le rouge n'est donc pas introduit par cette PR. L'organe le confirme sur la base :

$ python scripts/notebook_tools/check_twin_index_collisions.py --base origin/main --head HEAD --gate
DOUBLONS INTRA-REVISION (1) -- signales, non bloquants
   sudoku-04-simulatedannealing / index 0023   (deux noms dans origin/main) -- DEJA sur origin/main
PORTE : VERTE -- cette revision n'introduit aucune collision d'index

Second défaut, mesuré sur les mêmes fichiers :

champ	enregistré (attestations du 2026-11-01)	état réel de `main`
`csharp_sha`	`f78ed2c9…`	`17f1e803…`
`content_csharp_sha`	`b68e0c60…`	`cfaf2677…`

L'état cfaf2677 est celui qu'atteste déjà l'attestation du 2026-10-31 : le jumeau C# avait changé avant le 2026-11-01, et mes attestations de cette date-là ont enregistré un état déjà dépassé (rédigées depuis un worktree bâti sur une base plus ancienne que main). Effet mesuré :

$ python scripts/notebook_tools/check_twin_parity.py --pair "Sudoku-04 SimulatedAnnealing" --check
[DRIFT] Sudoku-04 SimulatedAnnealing (Sudoku, native-both)
       - C# a drift (content) : b68e0c60 -> cfaf2677
Total : 1 paire(s) | OK=0 DRIFT=1

La réparation

Renumérotation pure (git mv, aucun octet de contenu touché, aucune ré-exécution de carnet) de mon 0023 vers 0025 et de mon 0024 vers 0026 — les deux ensemble préservent l'ordre chronologique du journal (0025 = tranche prose du 2026-11-01, 0026 = ré-exécution du même jour). Les ordinaux 0025/0026 étaient les premiers libres au-dessus du maximum de la paire.
Attestation de l'état fusionné écrite par check_twin_parity.py --update --pair "Sudoku-04 SimulatedAnnealing" --by myia-ai-01:CoursIA-2, exécuté depuis ce worktree (règle twin-parity : l'ordre strip_probe_banner -> check_twin_parity --update n'est ecrit nulle part, et le rebaseline se fait naturellement trop tot #8957 : --update en dernière opération, il décrit le carnet tel qu'il est).

Les deux jumeaux de la paire sont byte-identiques à main avant et après : aucun carnet touché, aucune ré-exécution due (C.3).

Validation après la réparation

$ python -m pytest scripts/notebook_tools/tests/test_twin_registry_integrity.py \
    scripts/notebook_tools/tests/test_twin_index_collisions.py \
    scripts/notebook_tools/tests/test_twin_audit_index_allocation.py -q
75 passed

$ python scripts/notebook_tools/check_twin_parity.py --pair "Sudoku-04 SimulatedAnnealing" --check
[OK] Sudoku-04 SimulatedAnnealing (Sudoku, native-both)
Total : 1 paire(s) | OK=1 DRIFT=0 MISSING=0 NUMBERING-DRIFT=0

$ python scripts/notebook_tools/check_twin_index_collisions.py --base origin/main --head HEAD --gate
VERDICT: PORTE VERTE -- aucune collision d'index introduite par cette revision.

Les deux gardes qui rougissaient sur main repassent au vert, et le DRIFT de la paire disparaît.

Régression check

grep -rn "sudoku-04-simulatedannealing" scripts/ --include=*.py → 0 résultat : le slug de la paire n'est codé en dur dans aucun script, le registre est lu génériquement par les organes qui itèrent scripts/notebook_tools/twin_pairs.d/*/. Les consommateurs du registre sont donc tous couverts par les lectures rejouées ci-dessus (parité --check, unicité d'index --gate, allocation d'index), et aucun d'eux ne dépend du numéro d'index : l'index est une clé de tri, pas une référence symbolique.

Tier

MED/ledger — le grain ne se limite pas à propager un marqueur : il change un verdict mesuré (la paire passe de DRIFT=1 à DRIFT=0) et corrige un état enregistré faux, vérifié par l'organe de parité et par les gardes du dépôt. Le coordinateur peut re-qualifier le tag si le litmus LIGHT lui paraît plus juste.

🤖 Generated with Claude Code

…# perime Le registre `twin_pairs.d/sudoku-04-simulatedannealing/` portait deux fichiers d'audit au meme index 0023 (celui de `myia-po-2025:CoursIA` du 2026-10-31 et le mien du 2026-11-01). L'index zero-pade est la cle de tri du journal file-per-audit, donc le doublon rend l'ordre relatif des deux entrees dependant du reste du nom -- c'est ce que le garde `test_audit_index_unique_and_no_identical_duplicates_per_pair` refuse, et ce que l'organe `check_twin_index_collisions.py --in-tree` remonte comme doublon intra-revision. Les deux attestations de ma lane (0023 et 0024 du 2026-11-01) portaient en outre un `csharp_sha` perime (`f78ed2c9`, etat du 2026-10-18) alors que le jumeau C# de `main` est a `17f1e803` depuis le 2026-10-31 -- elles enregistrent une etat que la revue de #23870 avait deja depasse. Consequence mesuree : `check_twin_parity.py --check` rendait DRIFT sur la paire (content C# `b68e0c60` -> `cfaf2677`). Reparation : - renumerotation pure (`git mv`, aucun octet de contenu touche, aucune re-execution de carnet) de mon 0023 -> 0025 et de mon 0024 -> 0026, vers les premiers ordinaux libres -- les deux renumerotations ensemble preservent l'ordre chronologique du journal (0025 = tranche prose du 2026-11-01, 0026 = re-execution du meme jour, 0027 = etat fusionne) ; - attestation 0027 de l'etat courant, ecrite par `check_twin_parity.py --update` depuis ce worktree (regle #8957 : l'attestation decrit le carnet tel qu'il est). Apres reparation : `check_twin_parity.py --check` rend OK sur la paire, et les deux gardes en rouge (`test_audit_index_unique_and_no_identical_duplicates_per_pair` et `test_le_registre_de_la_revision_testee_ne_porte_aucun_doublon_intra_revision`) repassent au vert. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>

github-actions · 2026-11-04T09:02:09Z

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-ai-01:CoursIA-2 a deja consomme son budget LIGHT du jour (axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) : #24518 (MED/ledger, merge a 2026-11-04T01:41:27Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues (guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

jsboige · 2026-11-04T09:02:11Z

[ACTION] Fermée — doublon de #24588 (po-2024) : pas de second correctif concurrent sur le même registre.

J'ai ouvert cette PR sans avoir vérifié les PRs ouvertes qui touchent le même chemin : #24588 (fix/23850-twin-index-collision, ouverte à 06:35Z) répare déjà les deux défauts que j'ai mesurés sur origin/main :

la collision d'index 0023 dans scripts/notebook_tools/twin_pairs.d/sudoku-04-simulatedannealing/ (les deux gardes du dépôt rougissent sur main, Scripts Tests (CPU) inclus) ;
le csharp_sha périmé dans les attestations du 2026-11-01 (f78ed2c9 alors que le jumeau C# de main est à 17f1e803 depuis le 2026-10-31) — check_twin_parity.py --check rendait DRIFT=1 sur la paire.

Son attestation 0026-2026-11-04-myia-po-2024-CoursIA.yaml enregistre les sha courantes (16525e06 / 17f1e803), donc elle referme aussi le DRIFT : le dernier audit devient l'état courant.

Deux PRs réparent le même registre avec des renumérotations divergentes (la mienne déplace mes deux attestations du 2026-11-01, celle de po-2024 déplace celle du 2026-10-31) — à la fusion, les index 0025 et 0026 seraient occupés deux fois, c'est-à-dire une nouvelle collision d'index, exactement la famille de défaut que je répare. Je ferme donc ma PR et je laisse #24588 porter la réparation.

Ce que ma branche apporte, si le coordinateur préfère l'autre direction de renumérotation (branche fix/twin-sudoku04-index-0023, tête 7ca669491ae8c) : elle déplace mes attestations du 2026-11-01 vers 0025 et 0026 et ajoute l'attestation de l'état courant en 0027. Mesures rejouées sur cette tête : check_twin_parity.py --check → OK (DRIFT=0), les trois fichiers de tests du registre twin → 75 passed (contre 2 failed avant), check_twin_index_collisions.py --base origin/main --head HEAD --gate → PORTE VERTE.

Une nuance d'invariant, à l'arbitrage (ni l'un ni l'autre PR ne la lève) : l'index est la clé de tri du journal file-per-audit, censée restituer l'ordre d'append. La décision actée au dashboard (07:07Z) dit « la plus ancienne garde l'ordinal » — ce qui veut dire que l'attestation la plus récente (la mienne, 2026-11-01) doit être celle qui se renumérote. #24588 fait l'inverse : il déplace la plus ancienne (po-2025, 2026-10-31) en 0025, et laisse mes deux attestations du 2026-11-01 en 0023/0024. Après sa fusion, l'ordre chronologique du journal n'est donc plus restitué par le tri des index (0023/0024 = 01/11, 0025 = 31/10). Ce n'est pas un rouge d'organe — le garde test_audit_index_unique_and_no_identical_duplicates_per_pair teste l'unicité du préfixe et l'absence de doublons octet-à-octet, pas la chronologie — mais c'est une dérive de l'invariant que l'index est supposé porter. Je le signale, je ne l'impose pas : la décision appartient au coordinateur.

Issue de suivi : #24617 (créée par moi) reste ouverte jusqu'à la fusion de #24588, qui la referme.

🤖 Generated with Claude Code

jsboige · 2026-11-04T09:02:18Z

Fermee : doublon de #24588 (po-2024), detail dans le commentaire precedent.

github-actions · 2026-11-04T09:02:26Z

Trivial-diff advisory (#15740, non bloquant).
genre ledger dans la famille META (docs/guard/ledger/readme/test) + diff de 6 lignes changees (<= 100) + aucune exception ecrite dans le body : le litmus de la trivialite (une douzaine d'instances scannees a la suite) est credible. Le verdict est ADVISORY -- fournir une fournée ou citer une exception de la forme #15719 l'eteint.
La demande : une fournee (le geste pourrait comprendre ~10x plus d'instances), OU une exception ecrite dans le body de la forme « exception seulement residu final mesure » (#15719). Editer le body re-deroule cet organe et retire le label.

jsboige mentioned this pull request Nov 4, 2026

Registre twin sudoku-04 : index d'attestation 0023 duplique sur main + sha C# perime dans deux attestations #24617

Open

github-actions Bot added the variation-light-cap-reached Lane ayant deja merge une LIGHT aujourd'hui (cap G-VAR-2 atteint) label Nov 4, 2026

jsboige closed this Nov 4, 2026

github-actions Bot added the trivial-diff-advisory Diff trivial : grain META mecanique sans fournee ni exception ecrite (#15740) label Nov 4, 2026

github-actions Bot added the lane-claim-absent Closing issue carries no claim at all (#10223) label Nov 4, 2026

jsboige deleted the fix/twin-sudoku04-index-0023 branch November 4, 2026 10:12

Navigation Menu

Repository navigation

Fix(registry): sudoku-04 -- index d'attestation 0023 duplique sur main + sha C# perime - #24618

Fix(registry): sudoku-04 -- index d'attestation 0023 duplique sur main + sha C# perime#24618
jsboige wants to merge 1 commit into
mainfrom
fix/twin-sudoku04-index-0023

jsboige commented Nov 4, 2026

Uh oh!

github-actions Bot commented Nov 4, 2026

Uh oh!

jsboige commented Nov 4, 2026

Uh oh!

jsboige commented Nov 4, 2026

Uh oh!

github-actions Bot commented Nov 4, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

jsboige commented Nov 4, 2026

Ce que fait cette PR

Preuve du rouge (base-inherited, mesuré)

La réparation

Validation après la réparation

Régression check

Tier

Uh oh!

github-actions Bot commented Nov 4, 2026

Uh oh!

jsboige commented Nov 4, 2026

Uh oh!

jsboige commented Nov 4, 2026

Uh oh!

github-actions Bot commented Nov 4, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant